A Transaction Is One Unit of Work

Data changes rarely arrive alone: a transfer must debit one account and credit another, and an order must reserve stock and record a payment. If the system stops halfway through, the database is left describing a world that never existed. A transaction is the database's answer to that problem — a sequence of one or more operations that the database treats as a single, indivisible unit of work.

All of it, or none of it

Inside a transaction, every operation belongs to one outcome. The database never exposes a finished state in which only part of the transaction happened. The classic illustration is a transfer between two bank accounts: reduce the balance of the source account, then increase the balance of the destination account. If only the first step succeeded, money would vanish; if only the second, money would appear from nowhere. Wrapping both steps in one transaction removes both possibilities.

This all-or-nothing guarantee is called atomicity. Commit is the act that makes the transaction's changes permanent; a transaction that never commits leaves no trace at all. Durability adds the final piece: once a commit has returned, the change survives even if the machine loses power a moment later.

A transaction is a boundary

It helps to picture a transaction as a boundary drawn around a group of statements. Before the boundary and after it, the data satisfies the rules the structure imposes. Inside the boundary, intermediate states exist — one account is already debited while the other is not yet credited — but those states are private to the transaction. Later statements in other sessions do not treat them as the truth.

Two jobs at once

Transactions therefore do two jobs. The first is failure handling: if the process crashes, the connection drops, or a statement raises an error, the database can restore the state that existed before the transaction began. The second is visibility control: while the work is in progress, other readers are shielded from the unfinished result. These two jobs are related but not identical — atomicity decides whether changes are kept, while visibility is governed by isolation, the setting that controls how much concurrent transactions may see of each other.

Keep the unit on one connection

Transaction state belongs to a connection or session, so the statement that opens the transaction and the commit that ends it must run on the same connection. Many drivers also run in autocommit mode, where every single statement is its own transaction — a multi-statement unit needs autocommit switched off or an explicit start.

A Transaction Is One Unit of Work

Wrapping both steps in one transaction removes both possibilities. Core Concepts: transaction — a sequence of one or more operations executed as a single indivisible unit of work.

QUESTION 1

Which statement best describes a database transaction?

A sequence of one or more operations treated as a single indivisible unit of work.

A log file that records every statement the database has ever executed.

A backup copy of the database taken before any changes are made.

A single SQL statement that changes one row.

QUESTION 2

A transfer debits the source account, and then the server loses power before the credit runs. The transaction was never committed. What does the database guarantee when it restarts?

Only the debit is kept, because it executed first.

The debit is kept and the credit is re-applied automatically.

Both changes are kept but marked as incomplete.

Neither change survives; the incomplete transaction is undone during recovery.

QUESTION 3

What is the difference between COMMIT and ROLLBACK?

They are synonyms; both make the changes permanent.

COMMIT ends the current statement; ROLLBACK ends the whole session.

COMMIT makes the transaction's changes permanent; ROLLBACK discards them and leaves the data as it was before the transaction began.

COMMIT stores a copy of the data; ROLLBACK restores that copy.

QUESTION 4

A developer says: "Because my transfer runs inside one transaction, no other session can possibly see the debit before the credit." Is this correct?

No, because other sessions can always see uncommitted data in every database.

No; atomicity decides whether the changes are kept, while visibility is governed by isolation, so another session may still read uncommitted values depending on the isolation level.

Yes; atomicity hides every intermediate state from all other sessions.

Yes, but only if the transaction is kept very short.

QUESTION 5

A commit returns successfully, and the machine loses power a moment later. What does the database guarantee after recovery?

The committed changes are still there, because durability guarantees that committed changes survive crashes and restarts.

Only the last statement of the transaction survives.

The transaction is rolled back automatically after the restart.

The changes are lost because the power failure happened before the next checkpoint.

Case Study: The Interrupted Transfer

Read the scenario below and answer the two questions.

An application moves 100 from account 1 to account 2. It runs START TRANSACTION, then UPDATE accounts SET balance = balance - 100 WHERE id = 1. Before the second UPDATE can execute, the network connection to the database drops and the application process crashes. The accounts table has a check constraint that keeps balances non-negative. When the application restarts, it opens a new connection and finds no trace of the transfer having completed, and the balances on both accounts still look exactly as they did before the attempt.

From the database's point of view, what happens to the debit, and which guarantee explains it?

Answer:
The debit never becomes a finished result because the transaction never committed. A transaction is one unit of work, and atomicity means the whole unit applies or none of it does. When the connection ends, the database rolls the transaction back — or performs the same undo during crash recovery — restoring the state that existed before the transaction began. There is therefore no state in which 100 has left account 1 without arriving in account 2, so no money disappears.

The application is later refactored to use a connection pool. Why must the first UPDATE and the commit run on the same connection or session, and what role does autocommit play?

Answer:
Transaction state belongs to a connection or session, so the statement that opens the transaction and the commit that ends it must be issued on the same connection. If a pooling layer routes the later statements to a different connection, the commit applies to a different unit of work and the original transaction is left open or rolled back at disconnect, which breaks the boundary the application intended. Autocommit matters because most drivers run in autocommit mode by default, where each statement is its own transaction; in that mode the debit would become permanent the instant it ran, and no all-or-nothing unit would exist at all. A multi-statement unit therefore requires autocommit to be switched off or an explicit start of the transaction.